Good questions.First, all my latest DDT Designers are based on the EZGUI 4.0 Visual Designer (I reused the original 4.0 Pro designer code and then modified it to handle DDT).
The DDT Designers can read EZGUI 4.0 Pro form files.
Features specific to EZGUI 4.0 Pro are removed from the DDT Designers, since they would not be able to support them via generated code (ie. ownerdraw Buttons, Canvas control, Properties Listbox control, etc.).
What would be useful for DDT design is left in the Designers.
So why so many different designers ?
EZGUI 4.0 Professional is my top of the line Visual Designer and will remain so. The reason is that the more advanced features really can only be done using a runtime engine. This is what makes EZGUI 4.0 Pro different from its competitors. The runtime engine is the best way to handle such complexities. While other Designers come close in some features, like FireFly (in such things as common control support), they don't compare to the level of features found in EZGUI 4.0 Pro (ie. ownerdraw engine, graphics engine, print engine, thread engine and so much more).
There are two reasons to create other Visual Designers, particularly using DDT.
(1) EZGUI 4.0 Pro's price is out of reach of many.
(2) Many prefer a 100% source code solution (no runtimes).
While a 100% source code designers could never compare to EZGUI 4.0 Pro, they can though offer solutions to a much larger market, not currently tapped by EZGUI 4.0 Pro.
The first commercial DDT Designer released is the EZGUI Utility Dialog Designer. It is actually based on the coming EZGUI Dialog Designer Studio which will offer many more advanced features and controls (ie. common controls). It offers a low cost solution. It also is way to get some feedback which will benefit the Studio Designer while I am finishing it up. The Studio Designer will cost more, but will not be any where near the price of EZGUI 4.0 Pro (I am thinking of somewhere from $79 to $99).
Both of these Designers offer a low cost solution, 100% source code solution (no runtimes) and DDT compatibility so one can use all the new DDT commands in PB 8.0 and 9.0.
So why another DDT Designer besides these ?
The Utility and Studio Designers have two aspects which may not be desirable to DDT programmers.
(1) They depend upon a source code library of routines to work and those libraries can not be distributed to other parties (they are copyrighted material).
(2) They are Event based, similiar to EZGUI 4.0 Pro. I prefer their Event based style of coding, but many who have put a lot of time into learning DDT and the API, may not.
So this brings me to the EZGUI Layout Designer:
Why call it a Layout designer ?
Because it is not meant to replace a GUI engine. It won't offer a bunch of API wrappers, library code, etc. It will be purely based on DDT and will generate 100% inline code (no calls to library code).
Its purpose is simply for GUI layout and no more. GUI design will be quick and clean.
So what makes it different from PB Forms ?
The Smart Parser !
The Designer uses the same Smart Parser technology found in EZGUI 4.0 Pro. This will make GUI design (or layout) much easier and faster, even for beginners.
Those who are new to the Windows API, won't have to worry about a lot of API terms when designing visually. No window styles are refered to in the designer, just like EZGUI 4.0 Pro.
The difference is that the designer will convert the easy to design GUI to DDT code for you and you don't have to worry about how it works.
Now this is where is gets interesting.
Since no library code is used, you will be able to distribute the entire source code to your apps to others or post it on the PB forums. This can't be done with my other commercial DDT designers.
I will be enhancing the extensibility of the code generator, so users can easily create extensions to the designer to add their own code and to generate support code. This improved extensibility should allow users to share code via templates, plugins, etc. to allow the community of PB'ers to enhance the designer beyond its basic functions.
Lastly the Designer will not use events, but will generate pure dialog procedure and control callback code, which most DDT users are familiar with. I believe this will be preference for most DDT'ers.
So each Designer will service a different target group of PB'ers.